Monitoring severity and duration of aberrant physiological parameters during a procedure

ABSTRACT

Systems and methods are provided for monitoring a patient during a procedure. A physiological parameter of a patient is monitored during a procedure at an associated sensor. Respective cumulative times are measured for which the monitored physiological parameter of the patient meets each of a plurality of threshold values during the procedure. A risk metric is calculated for the patient, representing an effect of monitored physiological parameter on a patient outcome related to the procedure from the measured cumulative times for which the monitored physiological parameter of the patient met each of the plurality of threshold values.

RELATED APPLICATION

The present application claims priority to U.S. Provisional PatentApplication Ser. No. 61/712,875 filed Oct. 12, 2012 entitled DETECTIONOF HYPOTENSIVE EXPOSURE DURING ANESTHESIA under Attorney Docket NumberCCF-021682 US PRO, the entire contents of which being incorporatedherein by reference in its entirety for all purposes.

FIELD OF THE INVENTION

The present invention relates to systems and methods for monitoringpatients under anesthesia or procedural sedation and, in particular, isdirected to systems and methods for monitoring severity and duration ofaberrant physiological parameters during a procedure.

BACKGROUND OF THE INVENTION

Anesthesia has traditionally meant the condition of having sensation,including the feeling of pain, blocked or temporarily taken away. It isa pharmacologically induced and reversible state of amnesia, analgesia,loss of responsiveness, loss of skeletal muscle reflexes or decreasedstress response, or all simultaneously. These effects can be obtainedfrom a single drug which alone provides the correct combination ofeffects, or occasionally a combination of drugs, such as hypnotics,sedatives, paralytics and analgesics, to achieve very specificcombinations of results. This allows patients to undergo surgery andother procedures without the distress and pain they would otherwiseexperience. An alternative definition is a “reversible lack ofawareness,” including a total lack of awareness (e.g. a generalanesthetic) or a lack of awareness of a part of the body such as aspinal anesthetic.

SUMMARY OF THE INVENTION

In accordance with an aspect of the present invention, a method isprovided for monitoring a patient during a procedure. A physiologicalparameter of a patient is monitored during a procedure at an associatedsensor. Respective cumulative times are measured for which the monitoredphysiological parameter of the patient meets each of a plurality ofthreshold values during the procedure. A risk metric is calculated forthe patient, representing an effect of monitored physiological parameteron a patient outcome related to the procedure from the measuredcumulative times for which the monitored physiological parameter of thepatient met each of the plurality of threshold values.

In accordance with another aspect of the present invention, anon-transitory computer readable medium stores machine executableinstructions executable at an associated processor to predict patientoutcomes related to a procedure. A feature extractor is configured toprovide a plurality of features from a physiological parameter measuredfor a patient during the procedure. The plurality of features includesat least cumulative time periods for which a value of a parameter meetsvarious thresholds of the monitored parameter. A predictive model isconfigured to calculate a risk metric, representing an effect ofmonitored physiological parameter on a patient outcome related to theprocedure from the measured cumulative times for which the monitoredphysiological parameter of the patient met each of the plurality ofthreshold values. A user interface is configured to provide thecalculated risk metric to a user in a human comprehensible form.

In accordance with yet another an aspect of the present invention, asystem for predicting patient outcomes relating to a procedure isimplemented on at least one dedicated hardware device. The systemincludes a sensor configured to detect physiological parameters of apatient during the procedure and a user interface. A processing assemblyis configured to compare the detected physiological parameter to aplurality of defined ranges, record cumulative times for which themeasured physiological parameter deviate from each of the definedranges, and notify an operator each time the cumulative time thatmeasured physiological parameters exceeds a maximum time associated witha given defined range, portending a certain percent increase in risk ofadverse outcome.

In accordance with still another aspect of the invention, a method isprovided for detecting hypotensive exposure during anesthesia. A bloodpressure of a patient is monitored during a procedure at a bloodpressure sensor. Respective cumulative times for which the bloodpressure of the patient was below each of a plurality of thresholdvalues during the procedure are measured. A user is alerted when any oneof the cumulative times exceeds a predetermined exposure limit for itsassociated threshold value, portending a certain percent increase inrisk of adverse outcome. Furthermore, a final risk score can be providedat the end of a procedure based on the total number of exposure limitsthat were exceeded over the course of the procedure.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other features of the present invention will becomeapparent to those skilled in the art to which the present inventionrelates upon reading the following description with reference to theaccompanying drawings, in which:

FIG. 1 illustrates a system for predicting the likelihood of adverseoutcomes related to a procedure in accordance with an aspect of thepresent invention;

FIG. 2 depicts one example of a patient monitoring system in accordancewith an aspect of the present invention;

FIG. 3 illustrates a method for predicting a patient outcome from aphysiological parameter recorded during the procedure in accordance withan aspect of the present invention;

FIG. 4 illustrates an example method for monitoring a mean arterialblood pressure during a procedure utilizing anesthesia in accordancewith an aspect of the present invention;

FIG. 5 is a chart illustrating a percentage likelihood of 30-daymortality for a patient as a function of a number of hypotensiveexposure limits exceeded in the method of FIG. 4 and a CharlsonComorbidity Index;

FIGS. 6-11 illustrate the results of a study of the effects ofhypotensive thresholds on patient outcomes from procedures underanesthesia; and

FIG. 12 depicts an example of a decision support system that mightimplement systems and methods in accordance with an aspect of thepresent invention.

DETAILED DESCRIPTION OF THE INVENTION

As part of anesthesia, it is common for patients to experience adecrease in blood pressure. Severe enough blood pressure decreasesduring anesthesia have the potential for adversely affectingpostoperative patient outcome. Other, similar conditions, such ashypoxia, can also result in adverse outcomes. Accordingly, the use ofanesthesia is associated with considerable risk not only the procedurebut also with regard to post-procedure complications, such as morbidityand death within thirty days. The present invention addresses the needto be able to detect deviations in physiological parameters havingsufficient severity and duration to portend adverse patient outcome inthe days and weeks following a procedure. FIG. 1 illustrates a system 10for predicting the likelihood of adverse outcomes related to a procedurein accordance with an aspect of the present invention. In oneimplementation, the adverse outcome can be one of in-hospital morbidityor mortality, morbidity or mortality within a thirty-day period after aprocedure, an increase in length of hospital stay, or readmission to ahospital within a thirty-day period after a procedure. Specifically, theillustrated system 10 utilizes parameters derived from biometricmeasurements taken during the procedure, for example, while the patientis under general anesthesia. It will be appreciated that the illustratedsystem 10 can be implemented as dedicated hardware, for example,implemented within a sensor assembly for sensing the physiologicalparameter, software instructions stored on one or more non-transitorycomputer readable media operatively connected to an associatedprocessor, or a combination of hardware and software. Dedicated hardwaredevices for implementing the system can include, for example,application specific integrated circuits (ASICs), programmable logicdevices (PLDs), and field-programmable gate arrays (FPGAs).

An input interface 12 is configured to receive a plurality of parametersderived from physiological measurements taken during the procedure. Inone implementation, the input interface 12 can comprise machine readableinstructions for providing an input screen to a user to allow the userto enter the plurality of parameters via an appropriate input device(e.g., keyboard, mouse, microphone, camera, touch screen, etc.). In analternative implementation, the input interface 12 is configured tointeract with a medical database, blood pressure measurement device, orother automated data source to extract the plurality of parameters frommedical records, an anesthesia record, or native blood pressurerecordings associated with a given procedure.

These parameters are provided to a feature extractor 14. In accordancewith an aspect of the present invention, a plurality of features used inpredicting the likelihood of an adverse patient outcome includecumulative time periods for which a value of a parameter meets variousthresholds of the monitored parameter, that, the accumulated sum of thedurations of each incident in which the threshold is met. For example,in one implementation, the cumulative time for which a patient's meanarterial blood pressure falls below each threshold value is measured.The feature extractor 14 therefore analyzes the provided parameters anddetermines for each parameter threshold a cumulative amount of time forwhich the patient had value meeting the threshold. It will beappreciated that this can be repeated for multiple thresholds, with aseparate cumulative time spent below the threshold value determined foreach threshold value.

The parameters derived for the plurality of features are provided to apredictive model 16, which is configured to calculate a risk metricrepresenting a likelihood of an adverse patient outcome from theplurality of features as a linear or non-linear combination ofmathematical functions of the plurality of features. In oneimplementation, the mathematical functions are step functions, such thatthe function is a first value when the cumulative time for a giventhreshold value is below a value associated with the step function and asecond value when the cumulative time is above the value. Accordingly,in one example, the risk metric can comprise a number of mean arterialblood pressure thresholds that were met for cumulative times exceedingcertain predetermined values, such as one minute or a certain number ofminutes. In the illustrated implementation, each of the plurality offeatures has an associated weight, and the predictive model 16 providesa weighted combination of the plurality of features themselves or somemathematical function of each feature. It will be appreciated, however,that the predictive model 16 can utilize any appropriate classificationor regression model, such as an artificial neural network, a supportvector machine, a statistical classifier, or a similar model, tocalculate the risk metric, and that in some implementations, thecalculated risk metric can be categorical, such that it represents oneof a plurality of risk classes. A user interface 18 is configured toprovide the calculated risk matric to a user in a human comprehensibleform. Specifically, the user interface 18 interacts with a display,printer, speaker, or other appropriate output device to provide thecalculated likelihood of an adverse patient outcome to a user.

FIG. 2 depicts one example of a patient monitoring system 30 inaccordance with an aspect of the present invention. The system 30includes a plurality of sensors 32, depicted here collectively forsimplicity, to measure physiological parameters of a patient during aprocedure and, in the illustrated implementation, under anesthesia. Inone example, the plurality of sensors 32 can include sensors formonitoring one or more of electrocardiography (ECG) data, heart rate,blood pressure, inspired and expired gases, oxygen saturation of theblood (pulse oximetry), temperature, urine output, central venouspressure, pulmonary artery pressure and pulmonary artery occlusionpressure, cardiac output, cerebral activity, and neuromuscular function.In the illustrated implementation, one of the monitored parametersincludes a mean arterial blood pressure, and monitoring of the meanarterial blood pressure is used as an example for the sake ofexplanation. It will be appreciated, however, that the system 30 canmonitor other parameters or multiple physiological parameters in asimilar manner.

Data from the plurality of sensors 32 is provided to a processingassembly 34 that monitors and records the received data. In oneimplementation, the processing assembly 34 comprises a hardwareprocessor and software instructions stored on one or more non-transitorycomputer readable media, although it will be appreciated thatalternative implementations, such as dedicated hardware devices, arepossible. The processing assembly 34 includes, for selected parameters,respective defined ranges for the parameters, with the processingassembly 34 notifying a user of any deviations of the measuredparameters from the defined ranges that exceed associated maximumcumulative times at an associated user interface 36. In practice, theranges can be open ended, such that the range merely defines an upper orlower boundary for its associated parameter. It will be appreciated thatthe defined ranges can be specific to the patient, for example, toreflect other biometric parameters of the patient, such as age, existingmedical conditions, height, and weight. The user interface 36 caninclude any appropriate means for providing a visible or audible signalto the user, such as a display, an LED or other light-emittingindicator, and a speaker, as well as an input means, such as a touchscreen, mouse, keyboard, or microphone, for receiving instructions fromthe user.

In accordance with an aspect of the present invention, the plurality ofdefined ranges include a plurality of thresholds for theminute-to-minute mean arterial blood pressure, such that a user isalerted whenever the patient's cumulative time spent at a mean arterialblood pressure below a given one of the threshold values exceeds acorresponding exposure limit for the threshold. In one implementation, afirst threshold is defined at seventy-five mm Hg, and each successivethreshold is defined at a value one mm Hg less than that of thepreceding threshold up to a final threshold of forty-five mm Hg. As eachthreshold is met, the processing assembly 34 can monitor a cumulativetime for which the mean arterial blood pressure has been below thethreshold. These cumulative times can be compared to predeterminedexposure time limits, which can be generic or customized to the patientand/or by the user, and alert the user to the increased risk ofpost-procedure morbidity or mortality as the cumulative time approachesor exceeds these limits. The inventors have determined that thepredicted patient risk for increased 30-day mortality can be related tothe number of cumulative time limits exceeded for time spent below thevarious blood pressure threshold values. It will be appreciated that theextracted features can also include other relevant parameters, such asthe patient's age, the Charlson Comorbidity Index, and an amount ofblood lost by the patient during the procedure. It will further beappreciated that exposure limits portending equivalent risk may bedifferent for patients with different conditions such as a history ofhypertension.

In addition to alerting the user when a threshold is exceeded or anincrease in risk that occurs during a procedure, with the goal ofpotentially minimize any further progression of postoperative riskattributable to the aberrant physiologic parameter, the system 30 canalso be used to identify and stratify patients after the procedure formore intensive postprocedure follow-up care due to risk portended by theseverity and duration of aberrant levels of physiological parametersthat were experienced during the procedure. Such patients could betargeted for additional care and monitoring to minimize whatever effectsthe aberrant parameters may have on the patient outcome. For example, inthe case of hypotension, additional cardiac monitoring can be conductedboth within a hospital and after release of the patient to mitigate theincreased risk incurred due to the patient's hypotensive stateexperienced during the procedure, such as that reflected in the totalnumber of hypotensive exposure limits that were exceeded during theprocedure.

In view of the foregoing structural and functional features describedabove, a methodology in accordance with various aspects of the presentinvention will be better appreciated with reference to FIGS. 3 and 4.While, for purposes of simplicity of explanation, the methodologies ofFIGS. 3 and 4 are shown and described as executing serially, it is to beunderstood and appreciated that the present invention is not limited bythe illustrated order, as some aspects could, in accordance with thepresent invention, occur in different orders and/or concurrently withother aspects from that shown and described.

FIG. 3 illustrates a method 50 for predicting a patient outcome from aphysiological parameter recorded during the procedure in accordance withan aspect of the present invention. At 52, a physiological parameter ofa patient is monitored during a procedure at an associated sensor. At54, respective cumulative times are measured for which the monitoredphysiological parameter of the patient meets each of a plurality ofthreshold values during the procedure These cumulative times, along withother biometric and biographical parameters of the patient can be usedas a plurality of features for a predictive model. At 56, a risk metricis calculated for the patient, representing an effect of monitoredphysiological parameter on a patient outcome related to the procedurefrom the measured cumulative times for which the monitored physiologicalparameter of the patient met each of the plurality of threshold values.At 58, the calculated risk metric is provided to a user in a humancomprehensible form.

FIG. 4 illustrates an example method 70 for monitoring a mean arterialblood pressure during a procedure utilizing anesthesia in accordancewith an aspect of the present invention. At 72, a plurality of meanarterial blood pressure thresholds are defined for the patient. For easeof reference, the mean arterial blood pressure is represented as □(ABP)in FIG. 4 and an i^(th) mean arterial blood pressure threshold of asequence of thresholds is denoted in FIG. 4 as X_(i). The thresholdvalues as well as the maximum cumulative times permissible exceedingthese threshold values can be defined via any appropriate means,including individually for each patient based on a patient history as,for example, extracted from an electronic health records (EHR) system;applicable to certain patient populations (such as adult patientsundergoing non-cardiac surgery); selected as a list of standardthreshold values; derived from a determined minimum or maximum thresholdfor the patient and a standardized inter-threshold interval; or providedby a user at an associated input device.

At 74, various physiological parameters of the patient are monitored,including the minute-to-minute mean arterial blood pressure. It will beappreciated that this monitoring will generally be performedcontinuously or intermittently (such as within a certain number ofminutes, in accordance with applicable monitoring standards) throughoutthe method 70. At 76, it is determined if the mean arterial bloodpressure has fallen below any of the threshold values during a giveninterval. If not (N), the method returns to 74 where the biometricparameters continue to be monitored. If the mean arterial blood pressurehas fallen below one or more of the threshold values (Y), the methodadvances to 78, where a cumulative amount of time associated with eachthreshold is updated to reflect the amount of time that the patient'smean arterial blood pressure was below that threshold during a previousmeasurement interval.

At 80, the cumulative time for each threshold is compared to acorresponding exposure limit. For example, the various exposure limitscan be determined as a maximum amount of time that a patient can remainbelow the associated threshold without experiencing a certain increasein the risk of post-procedure morbidity or mortality. The exposurelimits can vary for the plurality of thresholds, and can bestandardized, determined individually for each patient according to anassociated patient history, for example, by querying an EHR database forcertain diagnoses or by entering such information via an appropriateinput device. In one implementation, the exposure limits can be selectedto be the time periods associated with certain progressive increases inpost-procedure morbidity or mortality that are portended by eachadditional exposure limit exceeded so as to provide an anesthesiologistan opportunity to react to the hypotensive state before it represents arisk of certain magnitude to the patient. In one example, dealing withblood pressure thresholds for monitoring hypotension, the exposurelimits can be selected according to a patient's absence or presence of ahistory of hypertension. An example of a standard set of applicableblood pressure threshold values as well as corresponding exposure timelimits for time accumulated below these thresholds (in minutes)portending various levels of risk for 30-day mortality in normalpatients is provided as Table 1. A corresponding table for patients witha history of hypertension is provided as Table 2.

TABLE 1 normotensive 5% 10% 15% 20% 25% 30% 35% 40% 45% 50% 75 26.6 51.976.1 99.3 121.5 142.8 163.4 183.2 202.3 220.8 74 22.9 44.7 65.5 85.5104.6 123.0 140.7 157.8 174.2 190.1 73 19.9 38.8 56.9 74.3 90.9 106.9122.3 137.1 151.4 169.2 72 17.5 34.1 50.1 65.3 79.9 94.0 107.5 120.5133.1 145.2 71 16.4 30.1 44.2 57.6 70.5 82.9 94.8 106.3 117.4 128.1 7013.6 26.5 38.8 50.7 62.0 72.9 83.4 93.5 103.2 112.7 69 11.9 23.3 34.244.6 54.5 64.1 73.3 82.2 90.8 99.1 68 10.5 20.6 30.2 39.4 48.2 56.7 64.972.8 80.3 87.7 67 9.3 18.2 26.7 34.8 42.6 50.1 57.3 64.2 70.0 77.4 668.3 16.2 23.8 31.1 38.0 44.7 51.2 57.4 63.3 69.1 65 7.3 14.3 21.0 27.433.6 39.5 49.1 50.6 55.9 61.0 64 6.7 13.0 19.1 24.9 30.4 35.8 40.9 45.950.7 59.3 63 6.0 11.7 17.1 22.3 27.3 32.1 36.7 41.1 45.4 49.6 62 5.310.4 15.2 19.9 24.3 28.6 32.7 36.6 40.5 44.2 61 4.7 9.2 13.5 17.6 21.625.4 29.0 32.6 36.0 39.2 60 4.2 8.3 12.2 15.9 19.4 22.8 26.1 29.3 32.335.3 59 3.7 7.2 10.6 13.8 16.9 19.9 22.8 25.5 28.2 30.8 58 3.2 6.3 9.312.1 14.9 17.5 20.0 22.4 24.7 27.0 57 2.8 5.5 8.1 10.6 13.0 15.3 17.419.6 21.6 23.6 56 2.4 4.7 6.9 9.0 11.0 13.0 14.8 16.6 18.4 20.0 55 2.04.0 5.9 7.7 9.4 11.0 12.6 14.1 15.6 17.0 54 1.7 3.4 5.0 6.5 8.0 9.4 10.712.0 13.3 14.5 53 1.5 2.9 4.3 5.6 6.9 8.1 9.2 10.3 11.4 12.5 52 1.3 2.53.7 4.8 5.9 7.0 8.0 8.9 9.9 10.8 51 1.1 2.1 3.1 4.1 5.0 5.9 6.7 7.5 8.39.1 50 0.9 1.8 2.6 3.4 4.2 5.0 5.7 6.4 7.0 7.7 49 0.8 1.6 2.3 3.0 3.64.3 4.9 5.5 6.0 6.6 48 0.7 1.3 2.0 2.6 3.1 3.7 4.2 4.7 5.2 5.7 47 0.61.2 1.7 2.2 2.7 3.2 3.7 4.1 4.6 5.0 46 0.5 1.0 1.6 2.0 2.4 2.8 3.3 3.74.0 4.4 45 0.5 0.9 1.3 1.7 2.1 2.6 2.9 3.2 3.6 3.9

TABLE 2 hypertensive 5% 10% 15% 20% 25% 30% 35% 40% 45% 50% 75 16.9 33.148.5 63.3 77.5 91.1 104.2 116.8 129.0 140.8 74 15.0 29.4 43.0 56.1 68.780.8 92.4 103.6 114.4 124.9 73 13.5 26.4 38.8 40.6 61.9 72.8 83.2 93.3103.0 112.4 72 12.3 24.0 35.2 45.9 56.2 66.1 75.6 84.7 93.6 102.1 7111.1 21.7 31.8 41.4 50.7 59.6 68.2 76.5 84.5 92.2 70 10.0 19.6 28.8 37.545.9 54.0 61.8 69.3 76.5 83.5 69 9.1 17.7 26.0 33.9 41.4 48.7 55.7 62.569.0 75.3 68 8.2 16.1 23.6 30.7 37.6 44.2 50.6 56.7 62.6 68.3 67 7.314.3 21.0 27.4 33.5 39.4 45.0 50.5 55.8 60.8 66 6.6 12.9 19.0 24.8 30.335.6 40.8 45.7 50.5 55.1 65 5.7 11.2 16.4 21.3 26.1 30.7 35.1 39.4 43.547.5 64 5.0 9.9 14.5 18.9 23.1 27.2 31.1 34.8 38.5 42.0 63 4.4 8.6 12.616.5 20.2 23.7 27.1 30.4 33.6 36.6 62 3.9 7.6 11.1 14.5 17.7 20.9 23.926.7 29.5 32.2 61 3.3 6.5 9.6 12.5 15.3 18.0 20.5 23.0 25.4 27.7 60 2.95.7 8.3 10.8 13.2 15.6 17.8 20.0 22.1 24.1 59 2.4 4.8 7.0 9.1 11.1 13.115.0 16.8 18.5 20.2 58 2.0 4.0 5.9 7.7 9.4 11.0 12.6 14.1 15.6 17.0 571.8 3.5 5.1 6.7 8.2 9.6 11.0 12.3 13.6 14.8 56 1.5 3.0 4.4 5.8 7.1 8.39.5 10.7 11.8 12.9 55 1.3 2.6 3.8 5.0 6.1 7.2 8.3 9.3 10.2 11.1 54 1.22.3 3.3 4.3 5.3 6.2 7.1 8.0 8.8 9.6 53 1.0 2.0 2.9 3.8 4.7 5.5 6.3 7.07.8 8.5 52 0.9 1.8 2.6 3.4 4.2 4.9 5.6 6.3 7.0 7.6 51 0.8 1.6 2.4 3.13.8 4.5 5.1 6.7 6.3 6.9 50 0.7 1.4 2.1 2.7 3.3 3.9 4.4 4.9 5.5 6.0 490.6 1.2 1.8 2.4 2.9 3.4 3.9 4.4 4.8 5.3 48 0.6 1.1 1.6 2.1 2.5 3.0 3.43.8 4.2 4.6 47 0.5 1.0 1.4 1.8 2.2 2.6 3.0 3.4 3.7 4.1 46 0.5 0.9 1.31.7 2.1 2.5 2.8 3.2 3.5 3.8 45 0.4 0.8 1.1 1.5 1.8 2.2 2.5 2.8 3.1 3.3

If none of the cumulative times exceed an associated exposure limit (N),the method returns to 74 to continue monitoring the biometricparameters. If an allowable exposure limit has been exceeded (Y), themethod advances to 82, where a risk metric associated with the patientis updated to reflect an increase in a risk of patient morbidity ormortality. In one implementation, a risk index can be computed from thismetric as an exponential function of the number of exposure limits thathave been exceeded. For example, the risk index, R_(I), can becalculated such that R_(I)=R_(B)(1.05)^(N), where R_(B) is a baselinerisk for a given patient given a patient history and any other relevantphysiological parameters measured, and N is the number of hypotensiveexposure limits that have been exceeded (FIGS. 5 and 8). At 84, theanesthesiologist or practitioner caring for the patient is alerted andinformed of the potential increase in risk to the patient. The methodthen returns to 74 to continue monitoring the biometric parameters.

FIG. 5 is a chart 90 illustrating a percentage likelihood of deathwithin thirty days (30-day mortality) for a patient as a function of anumber of hypotensive exposure limits exceeded in the method of FIG. 4and a Charlson Comorbidity Index. In the chart, 30-day mortality isrepresented on a first axis 92, the number of hypotensive exposurelimits exceeded is represented on a second axis 94, and CharlsonComorbidity Index is represented on a third axis 96. It will beappreciated from the chart that the number of hypotensive exposurelimits exceeded is a significant predictor of 30-day mortality,particularly for healthy patients, that is, patients with a low (<3)Charlson Comorbidity Index. Further, looking at the effects of eachindependent variable 94 and 96 on the 30-day mortality when the othervariable is at its lowest value, it appears that the number ofhypotensive exposure limits exceeded provides at least as muchdiscriminative power as the Charlson Comorbidity Index, considered ahighly relevant predictor of patient outcome.

The inventors have performed some research to provide evidence-basedguidelines on the effects of hypotension on procedural outcomes.Specifically, a study was designed to examine the relationship betweenintraoperative hypotension of varying severity and duration and 30-daypostoperative mortality following non-cardiac surgery. To this end, theregistries of Cleveland Clinic, of Hillcrest Hospital (a communityhospital within the Cleveland Clinic Health System) and of VanderbiltMedical Center were queried for data of 137,037 adult patientsundergoing non-cardiac surgery. Intraoperative minute-to-minute meanarterial blood pressure (MAP) recordings were analyzed for periods oftime spent below hypotensive thresholds ranging from 75 to 45 mm Hg. Theassociation was sought between cumulative time spent below this array ofthresholds and 30-day all-cause postoperative mortality derived from theSocial Security Master Index. Extracted information included patientdemographics (e.g., age, gender), a Charlson co-morbidity score, derivedfrom the patients' list of pre-existing diagnoses (problem list ICD-9codes), a type of anesthetic, a case duration, a cumulative amount ofdocumented blood loss, minute-to-minute mean arterial blood pressure(MAP) values, and all-cause mortality within 30 days of surgery,originating from the U.S. Social Security Death Index Master File.Preoperative hypertension was determined according to the presence ofany one of several ICD-9 codes (401.xx; 402.xx; 403.xx; 404.xx; or405.xx).

For each minute of every case, patients' effective MAP was considered tohave been the larger of the most recent automatically-acquirednon-invasive MAP value (obtained within the immediately preceding fiveminute period) or the most recent invasive MAP value acquiredcontemporaneously (continuously recorded at one-minute intervals),rejecting values less than 30 mm Hg as likely artifacts. For everypatient, the cumulative periods of time were calculated for which theeffective MAP was below each one of an array of hypotensive thresholdsranging from 75 to 45 mm Hg, using SQL Management Server 2008 and EXCEL2010 with VBA (Microsoft Corporation, Redmond, Wash.). Multivariablelogistic regression (UNISTAT 6.0, London, UK) was employed to ascertainwithin a development subset of patient records (35,904 patients,undergoing surgery on Cleveland Clinic's main campus between Jan. 1,2009 and Sep. 30, 2010) any factors significantly (p<0.05) associatedwith increased 30-day mortality, including the respective amounts oftime spent below each of the MAP thresholds between 75 and 45 mm Hg. Asa result, arrays of hypotensive exposure limits (for cumulative timespent below each of these MAP thresholds) were identified that wereassociated with a certain percent increase in the odds ratio for 30-daymortality, ranging from 5% to 50% (“smart sets”).

The validity of these new “smart sets” in portending adverse outcome wassubsequently further assessed in an additional 101,133 patient recordsfrom three different care settings (44,476 patients from ClevelandClinic main campus, undergoing surgery between Oct. 1, 2010 and May 31,2012; 27,610 patients from Hillcrest Hospital undergoing surgery betweenMay 2010 and May 2013; and 29,047 patients from Vanderbilt MedicalCenter, undergoing surgery between January and December, 2011), bycomparing their cumulative intraoperative hypotensive exposure timesagainst each of these “smart set” limits and examining the 30-daysurvival rates of patients exceeding these limits with those of patientsnot exceeding these limits.

Specifically, of 44,968 cases retrieved from Cleveland Clinic's maincampus between Jan. 1, 2009 and Sep. 30, 2010, a complete set of datawas obtained for 35,904 cases of patients who survived theintraoperative period and experienced an overall all-cause 30-daymortality of 2.1%. The average case duration was 204 minutes (range5-1169), with anesthetic techniques consisting of inhalationalanesthesia (82.9%), intravenous anesthesia (7.2%), spinal (4.9%),epidural (0.9%), peripheral nerve block (0.3%) and monitored anesthesiacare (3.9%). Intraoperative hypotension was common, with MAP dropping(for at least one minute) below 75 mm Hg in 92% of cases and below 45 mmHg in 10% of cases (FIG. 6). Dropping below a certain MAP thresholdcaused accumulation not only of time spent below that particularthreshold but of varying average amounts of time spent below each of theother MAP thresholds in the array above and below (the more time thehigher the threshold and vice versa, FIG. 6). Worsening hypotension (anyamount of time spent below progressively lower MAP thresholds) wasreflected by a progressive increase in the average cumulative amounts oftime spent below each of the other thresholds across the entire array ofMAP thresholds and, associated with this, a progressive increase in30-day mortality (FIG. 6). Preliminary multivariable logistic regressionidentified patient age (1.043, 1.037-1.049, per year), Charlsonco-morbidity score (1.193, 1.161-1.227, per increment) and cumulativeamount of blood loss (adjusted odds ratio of 1.038, 1.027-1.049, per 500ml) as independent predictors of 30-day mortality. All subsequentanalyses involving MAP were adjusted for these factors as well as caseduration.

The relationship between the severity of hypotension (the hypotensiveMAP threshold exceeded), the cumulative amount of time spent below thatthreshold and adjusted odds of 30-day mortality is depicted in FIG. 7.As demonstrated in the figure, the cumulative amount of time spent beloweach of the various MAP thresholds was independently associated with anincreased odds ratio for 30-day mortality. Furthermore, dropping belowprogressively lower MAP thresholds had a progressively greater adverseassociation with 30-day mortality per unit of time accumulated belowthat threshold. For any given MAP threshold, patients carrying apreoperative diagnosis of hypertension (prevalence of 40% according tothe definition above) required less cumulative time to be accrued belowthat threshold to incur the same increase in 30-day mortality odds ratioas patients without a history of hypertension. The resulting cumulativeexposure times below each of the MAP thresholds (in minutes) thatcorresponded to the same respective increases in the odds ratio of30-day mortality ranging from 5% to 50% (risk-based “smart sets”) arelisted in Tables 1 and 2.

Within each of these “smart sets”, the total increase in mortalityattributable to hypotensive exposures for any given patient dependedupon the total number of exposure limits exceeded within the “smartset”, with each incremental limit exceeded portending a compounding 5-7%further increase in the odds ratio for 30-day mortality (FIG. 8). Theaverage number of exposure limits exceeded within the various “smartsets” ranged from 17 in the 5% “smart set” to 11 in the 50% “smart set”(FIG. 8). The adverse effect of hypotensive exposures on 30-day survivalwas independent of and adjusted for the Charlson co-morbidity score.However, there was a significant statistical interaction betweenhypotensive exposures and the Charlson co-morbidity score: while agreater Charlson co-morbidity score portended overall progressivelygreater 30-day mortality, the relative (i.e., percent) increase inmortality of patients exceeding “smart set” limits was inverselyassociated with the co-morbidity score (Wald test, Bonferroni adjusted,p<0.05), suggesting that the more prevalent “healthier” patients withco-morbidity scores between 0 and 3 were affected more extensively thanless prevalent “sicker” patients with a co-morbidity scores of 4 orgreater). This is shown in FIG. 9 for patients either exceeding or notexceeding any one or more of the 20% “smart set” limits.

In the additional 101,133 patients examined, hypotensive exposures werecompared to each of the various risk-based “smart set” limits depictedin Tables 1 and 2, choosing the limits according to whether or notpatients carried a history of hypertension. The fraction of patientsexceeding any one of the exposure time limits ranged between 59-72% (5%“smart set”) and 8-14% (50% “smart set”) and was similar between thethree institutions tested (FIG. 10, dark lines). While the overall30-day mortality was also similar at the Cleveland Clinic main campus(1.6%) and at Vanderbilt Medical Center (1.7%), and was greater thanthat at Hillcrest Hospital (0.5%), those patients exceeding “smart set”limits exhibited a similar progressively greater, more than doubling of30-day mortality in each one of the three care settings (FIG. 10, upperlight lines) compared to those patients not exceeding any of these“smart set” limits (FIG. 10, lower light lines).

When examined in 94,351 of these 101,133 patients for which a Charlsonco-morbidity score could be obtained from the available data set, aninverse relationship was confirmed between the increase in mortality andthe Charlson co-morbidity score of patients exceeding (an average 12.9)exposure limits of the 20% “smart set” (FIG. 11). When being stratifiedaccording to the number of “smart set” limits exceeded (0; 1-6; 7-12;13-18; 29-24; >24), there was a progressive increase in mortality withthe number of “smart set” limits exceeded (FIG. 5). This association wasmost pronounced in the majority (93%) of healthiest patients with aco-morbidity score below 3 (FIG. 5).

This study has demonstrated that periods of intraoperative hypotensionwhich exceeded certain sets of cumulative exposure time limits wereindicative of progressively increased 30-day mortality followingnon-cardiac surgery and routinely encountered in a substantial fractionof patients, primarily affecting healthier rather than the very sickestpatients. Hypotensive exposures may thus a represent a conceivablycontrollable factor contributing to compromised long term outcome in asignificant fraction of surgical patients. While it is commonly acceptedthat severe hypotension is poorly tolerated, the inventors havedetermined that longer-term outcomes may also be affected by extendedperiods of less severe hypotension in patients surviving the immediateperioperative period. However, relatively little had been known aboutthe acceptable blood pressure ranges below which anesthesia providersshould be concerned not only about getting patients through the surgeryalive (and without major intraoperative complications), but also aboutminimizing any potential longer term adverse outcome. Efforts to datehad been largely concerned with trying to identify and avoid hypotensionbelow some distinct blood pressure threshold deemed to be criticallylow, consistent with the design limitation of conventional bloodpressure monitors which typically lack the ability to alert providers toanything but the most recent reading falling below a certain adjustablethreshold.

In contrast to conventional vital sign monitors, modern electronicanesthesia information systems can be adapted as described herein torealize the promise the potential of more sophisticated clinicaldecision support (DSS) functionality by being able to take intoconsideration more comprehensive information in real time, includingpertinent pre-existing conditions (such as a history of hypertension) aswell as both the severity and duration of patients' deviation fromcertain acceptable vital sign ranges over the course of an entire case.A desirable feature of the described systems and methods is the use of“smart” alarms designed to detect and alert providers to certain levelsof risk for adverse postoperative outcome attributable to suchdeviations in vital signs that may be amenable, to some extent, tocontrol by anesthesia providers. The study described herein was designedto test the hypothesis that postoperative outcome may be associated notonly with the severity of hypotension but also the duration ofhypotensive periods of time spent below a range of mean arterial bloodpressure (MAP) thresholds that are commonly encountered duringanesthesia.

The present data demonstrate a significant independent associationbetween the cumulative times accrued below a wide range of MAPthresholds commonly experienced during non-cardiac anesthesia (and notusually considered to be of concern by most anesthesia providers) andincreased all-cause mortality within 30 days after surgery. Thisassociation appears to affect a considerable fraction of patients (suchas one in every three patients for the 20% “smart set”), to not befocused on patients with high comorbidity but rather affect the majorityof patients with lower co-morbidity scores, and to similarly apply toboth major academic medical centers as well as a community hospital(even if the absolute 30-day mortality rates were different in thesecare settings).

Consistent with the existing literature, which has not been able toidentify any clinically meaningful threshold for hypotension, there doesnot seem to have been one particular blood pressure threshold having tobe dropped below to portend a greater risk for 30-day mortality versusbeing spared from such an effect. Rather, increased risk appears to havebeen related to an interaction between severity and duration ofhypotension below a wide range of commonly encountered MAP thresholds.In this sense, “smart set” limits appear to be somewhat analogous todiving charts, suggesting that less time may be permissible to be spentat a lower MAP (a greater depth) while incurring a similar amount ofrisk. The present data suggest that risk does not appear to besufficiently quantified by examining time accrued below just one MAPthreshold but rather below a wide range of commonly encountered MAPthresholds. Varying limits of cumulative exposure time need to beexceeded below these various MAP thresholds to incur an equivalentincrease in risk, each of these time limits being different for patientswith or without a preoperative diagnosis of hypertension (FIG. 9 andTables 1 and 2).

This particular type of approach to identifying acceptable bloodpressure thresholds is facilitated by the increasing availability ofelectronic anesthesia information systems. With the arrival of clinicaldecision support (DSS) functionality that offers nearly instantaneousaccess to all required information it is conceivable that notificationto such increased risk based on progressive hypotensive exposures can bemade available to the anesthesia provider in near real time.

While hypotension might theoretically be escaped altogether byminimizing the time a patient's MAP is permitted to drop below 75 mm Hg,this would be neither feasible in the reality of clinical practice norlikely desirable. In the present study, over 90% of patients' MAPdropped below 75 mm Hg at some point during their anesthetic. However,only approximately one third of patients did so long enough to exceed atleast one of the 20% exposure limits (FIGS. 8-10). The conceivablebenefit of DSS providing the suggested type of “smart alerts” in realtime is that these would allow permissive hypotension to be institutedwhenever indicated (such as to minimize bleeding) without invariablycausing the triggering of notifications (as would be the case withtraditional devices) while still keeping track of cumulative times spentin a hypotensive state and providing notification only toprovider-selectable increments of risk resulting from more prolongedperiods of hypotension. Patient benefit might be derived from minimizingapparently hazardous periods that may be spent gratuitously at a MAPbetween 60 and 70 mm Hg, a pressure range traditionally considered onlymildly hypotensive and not generally viewed as posing a problem for thepatient.

These data further suggest that patients may be readily detectable asbeing at an increased risk for adverse 30-day postoperative outcome andmay thus possibly be prioritized for more intensive follow-up care bythe time they leave the operating room theater on the basis of the totalnumber of risk-based “smart set” limits that were exceeded over thecourse of their surgical procedure. Contrary to conventional belief suchhypotensive exposures appear to not be limited to the sickest patientswith the very highest co-morbidity scores but are similarly prevalentacross all patients undergoing anesthesia. Furthermore, also contrary toconventional belief, the adverse impact of hypotensive exposures appearto be most pronounced in the large majority of (>85%) of healthiestpatients with lower comorbidity scores and may thus represent apotentially preventable factor threatening the best outcome of largenumbers of otherwise lower risk patients whose increase in their countof “smart set” limits exceeded may be detected in real time andconsequently prevented from further progression.

FIG. 12 depicts an example of a decision support system (DSS) 110 thatmight implement systems and methods in accordance with an aspect of thepresent invention. In the example of FIG. 12, the DSS 110 includes a DSSserver 112. The server can include one or more processor 114 and memory116. The memory can store data and machine readable instructions thatcan be executed by the processor 114. For example, the memory 116 cancomprise physical memory, such as can reside on the processor 114 (e.g.,processor memory), random access memory or other physical storage media(e.g., CD-ROM, DVD, flash drive, hard disc drive, etc.) or a combinationof different memory devices that can store the machine readableinstructions. The memory 116 further can be implemented within a singlemachine, as depicted in FIG. 12, or it can be distributed acrossmultiple machines. The data utilized for implementing the systems andmethods described herein can also be stored in the memory 116 or in someother arrangement of one or more memory structures that are accessiblefor use by the system 110.

The DSS server 112 can be connected to a network 118 such as to providefor communication between the DSS server and various services, devicesand data stores that can collectively form the system 110. The network118 can be a local area network, a wide area network, or a combinationof different various network topologies, which may include physicaltransmission media (e.g., electrically conductive, optical fiber mediaor the like) and/or wireless communications media, that can be utilizedfor communicating information. The network or at least a portion of themethods and functions implemented thereby can operate in a secure manner(e.g., behind a firewall separated from public networks) and/or utilizeencryption for data communications.

In the example of FIG. 12, the DSS server 112 can employ the network 118to access system data 120, an encounter server 122, as well as one ormore other services generally indicated at 124. These other services 124can correspond to various other servers that can store and provideinformation pertinent to a given patient encounter or to a patient'shealth condition, more generally. For example, these services can beused to retrieve patient data that may be useful in determiningappropriate cumulative exposure time thresholds for variousphysiological parameters for use in a procedure under anesthesia, suchas, for example, a history of hypertension. Such other services 124 mayalso execute methods and functions that can be utilized by the DSSserver 112, such as via corresponding application interfaces (APIs). Theparticulars of such other services 124 can vary according to theparticular purpose of the DSS 110.

The DSS server 112 can obtain information from a plurality of stations126, demonstrated as station 1 through station N, where N is a positiveinteger denoting the number of stations. The stations 126 can beassociated with one or more locations 128. For example, the location 128can correspond to a portion of a facility (a floor, a ward or the like),a facility itself or a plurality of different facilities for which theDSS 110 can be configured to provide clinical decision support.

In the example of FIG. 12, each station 126 can include a number of oneor more devices 130. Each of the devices 130 can be associated with agiven patient 132, demonstrated as Patient P1 through Patient PN. Thusin this example each station 126 can include a given patient, althoughit is understood that more than one patient could be associated with agiven station in other situations. The DSS 110 can be configured toprovide decision support for any number of one or more patientencounters, such as a procedure requiring general anesthesia. As usedherein a patient encounter corresponds to a record that is maintained bythe DSS 110 for each patient 132 during a time period for a given visit,such as can include their time for which they were monitored in a givenstation 126 (e.g., a perioperative period).

The devices 130, for example can obtain real time information about apatient condition that can be monitored during each active patientencounter. Such real time information can include, for example arterialblood pressure, including mean arterial blood pressure, venous bloodpressure, heart rate, temperature, respiration rate, pulse oximetry aswell as any other parameters that may be pertinent to the healthcondition of a patient during the encounter. The DSS server 112 canobtain information directly from such devices 130. Alternatively oradditionally, the DSS server can obtain corresponding patient data forthe encounter server 122 that may collect and process information fromone or more of the devices 130.

As an example, the encounter server 122 can include a station interface134 that can be utilized to acquire information from one or more of thedevices 130. The encounter server 122 can obtain such data at a desiredsample rate that might vary according to the type of information, suchas depending on the rate that each of the devices samples such data. Forexample, blood pressure readings may be performed by a blood pressuremonitor every five minutes whereas pulse oximetry or heart rate will besampled at much higher rates. It will be appreciated that these rateswill vary according to the specifics of a patient encounter. Forexample, during a procedure utilizing general anesthesia, more frequentmeasurement of various biometric parameters, including arterial bloodpressure, may be performed. The encounter server 122 can storeinformation from such devices 130 data as part of a patient encounter inmemory associated with the encounter server.

The encounter server 122 can also include an electronic health record(EHR) interface 136 that can be utilized to retrieve patient informationfrom an EHR database 140. For example, the encounter server 122 canemploy the EHR interface 136 to pull patient encounter data, as well asother pertinent patient records from the EHR database 140 (e.g., patientdemographic information, patient medical history, or the like). The DSSserver 112 can employ also the encounter server (e.g., as middleware)122 to obtain relevant patient information from the EHR database, suchas via an encounter interface (e.g., an API). The encounter server 122can also be programmed to store relevant encounter data back to the EHRdatabase 140.

In addition to health record data that may be stored in the EHR database140, the DSS server 112 can also access a knowledgebase 142 or one ormore other data sources, indicated at 144. The knowledgebase 142 can beutilized to access a variety of reference texts, medical publications,guidelines, policies and procedures and care algorithms that may beutilized by users of the system 110. The DSS server 112 can make suchinformation available to its users via dynamic or configurable links. Asan example, the DSS server 112 can present patient encounter informationto a user via one or more web pages that contain dynamic links (e.g.,hypertext links) to predefined resource locations (e.g., uniformresource locations (URLs)) at which pertinent information correspondingto the system data 120 can be provided. As described herein, the DSSserver 112 can be programmed to automatically select the informationaccording to the real-time conditions of the patient, preferences of theuser and other information related to an event that is occurring at agiven one of the respective stations 126. The DSS server 112 can providean encounter GUI that is populated with such selected information and/orlinks to such information.

In the examples described herein, the DSS server 112 can be implementedin a context of a perioperative patient management system. For instance,the DSS server 112 can provide timely patient encounter information,guidance and alerts to users so that informed decisions can be made in atime-critical environment. As mentioned above, data specific to eachactive patient encounter (associated with the respective station 126)can be acquired by the DSS server 112 from a variety of sources, such asincluding the encounter server 122, EHR data 140, the knowledgebase 142,other data sources 144 and/or other services 124 that may providepertinent information for the decision support process for each activepatient encounter.

Authorized users can employ a corresponding user device 146 to accessinformation generated by the DSS server 112. There can be any number ofuser devices 146 that can access the information from the DSS server112. A given user device 146 can include a user interface 148 thatallows the user to access the functions and methods implemented by theDSS server 112 as well as to retrieve related content information. Theuser interface 148, for example, can include a web browser (or a thinclient application) that can be provided dynamic links for accessing thefunctions and methods corresponding to the DSS server 112. It is to beappreciated that such user device 146 can be a computer, a work station,as well as a mobile device (e.g., a smart phone, laptop or tabletcomputer) that can run a corresponding application for accessing thefunctions and methods associated with the DSS server. The user device146 can be located in a corresponding station (e.g., in a OR) 126 aswell as can be implemented as a remote device, that can access theinformation produced by the DSS server 112, such as by accessingcorresponding screens via embedded web browser controls.

The DSS server 112 can also employ a messaging system 150 to sendmessages to respective users. For example, the user device 146 can alsobe a pager to which one or more alphanumeric messages can be sent fromthe DSS server via the messaging system 150. In this example, themessaging system 150 can correspond to a hospital paging system. Themessaging system 150 can also be implemented as a text messaging system,an automated phone messaging system, and/or an email or text messagingsystem for providing corresponding messages to respective users.

The DSS 110 can also provide alerts, other notifications and relevantinformation, corresponding to patient conditions that are monitored bythe DSS, to the users that can be received via the user device 146,including the various alerts representing a hypotensive state exceedingexposure limits for various mean arterial blood pressure thresholds, asdescribed previously. As further described herein, alerts can correspondto global types of guidance. Additionally, or alternatively, the DSSserver 112 can be configured by a given user to provide personalizedalerts and guidance to the given user. As a result, the system 110 canbe customized according to the individual preference of a given user.

Individual users having supervisory control or similar authorization mayalso be able to configure global types of guidance and global alertsthat will be provided to users in the system. In this way, the DSS 110can help improve patient outcomes, such as by reducing mistakes,reducing potential oversights and providing a mechanism for more timelyrecognition of conditions that may require user intervention, such asprolonged hypotensive exposures as described above. The DSS 110 can alsofacilitate on-demand learning by offering tools for investigatinginformation pertinent to a given patient condition via linksautomatically generated for an active patient encounter from theknowledgebase 142 or the other data 144.

The DSS server 112 can include a guidance engine 152 programmed toevaluate information and data pertinent to the evolving patientcondition for each active encounter in a given station 126. As mentionedabove, the guidance engine 152 can receive the patient encounter datafrom various devices 130, which may be directly monitoring patient'sconditions, as well as from data available from other sources such asthe system data 120, the encounter server 122 and other services 124.The guidance engine 152 can analyze such information and computedecision support data that can be presented to a user in the form ofreal-time assistance. The guidance engine can also search the systemdata 120 or other sources for pertinent patient information, guidelinesand procedures relevant to current circumstances of the active patientencounter. Data acquired by the DSS server 112 for each station 126 canbe stored in the memory 116 or another database, such as may be part ofthe system data 120.

As a further example, the DSS server 112 can include a synchronizationmodule 154 that can be utilized for sampling data from the encounterserver 122 as well as from each of the stations 126 and other services124 that may be associated with monitoring patient conditions. As oneexample, a programmable sampling time period can be specified for timingretrieval of information by the synchronization module 154 of the DSSserver and other services, such as the encounter server 22 during whichthe DSS server, via the synchronization module 154, can retrieveinformation. For instance, a mutually agreed upon time such as betweenthe 15th and 50th second of each minute can be set and programmed intothe synchronization module to minimize disruption with the ongoingactivity of the encounter server 122.

Examples of some conditions that can be monitored by the devices 130 ateach station 126 can include: EKG, pulse oximetry, blood pressure,temperature, respiration rate, or other parameters that can be monitoreddirectly from the patient. Additional information can be obtained fromthe devices 130 such as composite parameters based upon severalindependent parameters, for example a “triple Low” condition defined asa low bi-spectral index (BIS), mean arterial pressure (MAP), end-tidalanesthetic concentration (MAC). Alternatively, this and otherinformation and parameters can be computed by the DSS server 112 basedon data retrieved from any of the data sources.

As a further example, the following table demonstrates a sample set ofdata parameters that can be acquired by the DSS server 112 and wheresuch parameters may be obtained for an embodiment, based on whichdecision support and guidance can be provided:

TABLE 3 Parameter Data Source Airway Summary Encounter Parameter DataAllergies Encounter Parameter Data Anesthesia Type Encounter ParameterData ARKS Bolus Meds Encounter Bolus Meds Arterial Diameter EncounterMonitor Data Arterial Heart Rate Encounter Monitor Data Arterial MeanEncounter Monitor Data Arterial Sys Encounter Monitor Data BIS EncounterMonitor Data CO2 Encounter Monitor Data CVP Encounter Monitor DataDesflurane Encounter Monitor Data dPP Other Data dPP2 Other Data EHRMedical History EHR database (ICD-9 code) EPIC Medications EncounterMedications Fi O2 Encounter Monitor Data HR Encounter Monitor DataIsoflurane Encounter Monitor Data Mech Min Vol Encounter Monitor DataMedical History Encounter Parameter Data NBP Dia Encounter Monitor DataNBP Mean Encounter Monitor Data NBP Sys Encounter Monitor Data PatientPosition Encounter Parameter Data Regional Block Type EncounterParameter Data Sevoflurane Encounter Monitor Data Sp O2 EncounterMonitor Data SpO2 Variability Encounter External Data Temp 1 EncounterMonitor Data Temp 2 Encounter Monitor Data Warming Devices EncounterParameter Data

In Table 3, the data sources including the term “Encounter” can beobtained from the encounter server. Further, it will be appreciated thatany of the parameters listed above can be utilized in determiningpatient specific thresholds and exposure limits for a given patient, aswell as features, along with the measured cumulative time below eachthreshold, for a predictive model of post-procedure morbidity ormortality.

The guidance engine 152 can be utilized to provide passive guidance,active guidance as well as a combination of passive and dynamic guidanceto a user via a user device. The passive guidance can correspond topresenting the information directly as obtained from a device, such ascan be presented on a user device 146 in the form of text, graphics or acombination of texts and graphics showing various patient conditionssuch as vital sign trends. The passive guidance can also include linksto pertinent information that can be obtained from the system data 120or other services, such as links to various documents that may berelevant to the patient's 132 evolving condition, patient history orother information that can be obtained for an active patient encounterfrom the system data 120. This may include a search module 172 that canbe utilized to identify and locate content pertinent to a given patientencounter. The search module can provide the content directly or viahypertext links or otherwise. For example, the search module 172 cancorrespond to a commercially available or proprietary search engine thatcan be utilized to query the system data 120 or other resources forinformation and guidance that may be pertinent to the patient conditionbased upon the encounter data or a patient history data. For example,the search module 172 can query any number of one or more databases andsuch queries may be run periodically in response to the evolving datathat is collected by the DSS server for each patient encounter.

Individual instances of the search module 172 thus can be utilized foreach patient encounter for retrieving pertinent information for eachrespective patient. In addition to implementing such queries in responseto the real-time information, such data can be analyzed (e.g., by theguidance engine 152) to detect trends or time varying parameters thatmay indicate specific conditions for which the search module can in turnlocate relevant information that is presented to the user via theencounter GUI. Thus as described herein, the search module 172 mayemploy the results of expressions implemented by the guidance engine toimplement corresponding searches such that the information beingpresented to the user at a given user device 146 is timely and relevantto the patient's current and evolving condition.

As a further example, the guidance engine 152 can be programmed toprovide guidance, including dynamic or passive guidance, in response todetecting an adverse condition associated with a patient. For example,the guidance engine 152 can retrieve pertinent passive information(e.g., documents, procedures, or the like) in response to detecting avital sign or other indication of an adverse patient condition for agiven patient 132. The alert provided when a patient's cumulative timespent below a given mean arterial blood pressure threshold exceeds theacceptable exposure limit, as described previously, is one example ofguidance provided in response to detection of an adverse condition, andassociated passive content may include the display of available optionsto treat this condition, including the options to administer additionalintravenous fluids, inotropic medications or vasopressors, or to reducethe anesthetic depth.

The dynamic guidance can include results of analysis of the data thathas been obtained via the synchronization module 154 from the devices130, encounter server 122 or other services 124 for a given patientencounter. Thus it is to be understood that the DSS server 112 canretrieve, track and provide guidance separately for each patientencounter. The guidance engine 152 thus can be programmed to presentpertinent information, from both the dynamic and static content to theuser based upon rules or expressions that can be configured.

The global guidance module 158 can be configured for certain groups oracross an enterprise by establishing a set of global criteria upon whichthe guidance engine 152 will provide guidance, including passive anddynamic guidance as described herein. The global module 158, forexample, can be utilized to define parameters or other criteria such asin the form of dynamic expressions that control what content displays aswell as what actions are suggested to be performed. Guidance implementedwithin the global module 158 corresponds to guidance that is applicableto all users or a predefined set of users within the system. Forinstance, the global guidance module can be programmed to implementrules for providing generally applicable guidance, such as can be basedupon best practices evidence or other policies and procedures for agiven institution.

The personal guidance module 160 can be utilized by an individual userto control types of guidance (e.g., alerts or dynamic DSS webpagecontent) that is to be provided based upon user-defined parameters. Inthis way, each user may establish a set of personalized criteria basedon which guidance can be provided to such user. Different users canemploy different instances of the same personal guidance criteria (e.g.,corresponding to expressions). Each instance can employ the samethresholds or different thresholds for providing associated guidance. Anauthorized user can also convert a personal guidance expression to aglobal guidance expression, such as via a corresponding user interface162.

A user can employ the user interface 162 of the DSS server 112 that canaccess corresponding tools, such as may be part of a DSS manager 164.The DSS manager 164 can correspond to functions and methods that can beutilized to program or configure various aspects of the DSS 110. Theaccessibility of various functions and methods that can be accessed by agiven user can depend upon an individual's authorization or role withinthe system. For example, there can be any range of roles that can beestablished within the system 110, which may be based upon existingauthentication systems for an enterprise or network in which the system110 is being implemented. For instance, a supervisor or other individualwith a sufficient level of authorization can set the parameters forcontrolling the global guidance module 158.

A system administrator further may be able to create and configureinterfaces, such as including one or more device interfaces 166, tocontrol communication and retrieval of data from various resources inthe system 110. Additionally, an individual user can employ the userinterface 162 to access personal preferences via the DSS manager 164such as to establish parameters that control the personal guidancemodule 160 for such user. The device interface 166 can be configured toprovide access to the output data provided by the one or more devices130 that may be utilized in a given active station 126. The deviceinterface 166 thus can create a communications channel via the networkfor retrieving relevant data. The retrieved data can include raw data,processed data or a combination of raw and process data that can bepresented in the form of content to a given user.

By way of further example, each user that is logged into the system 110is recognized and their personal preferences and settings can beutilized for controlling what dynamic content and active guidance may beprovided to the individual according to the personal guidance module 160and other configuration settings that may be user-configurable. Bothglobal and personal settings can be stored as DSS parameters in the DSSdata 156 in the memory 116.

A notification engine 168 can be configured to establish mechanisms tobe utilized for communicating information to a given user. Similar tothe guidance engine 152, the notification engine 168 can employ globaland personal notification methods that are applied to users that arelogged into the system 110. Such global notification mechanism caninclude on-screen displays that can be color coded, flashing orotherwise indicate a condition that requires attention by theuser-physician. The notification engine 168 can also send messages to agiven user via the corresponding messaging system 150 in response todetecting certain conditions. Such conditions can be determined by theguidance engine 152, which can correspond to global guidance or personalguidance that may be set by the user.

A user can specify more than one mechanism to be utilized for sendingnotifications. For example, a user can configure the notification engine168 to alert an individual of an abnormal patient condition requiringattention via text messaging, paging, email, and/or other mechanisms viawhich a user can receive information. Thus in response to instructionsto send a notification (e.g., as determined by the guidance engine 152),the notification engine 168 can send such notification to an individualuser or to a group of users according to the notification parametersthat have been established.

As an example, a given user that is logged into the system 110 may be anowner of a patient encounter (e.g., having responsibilities for thepatient 132 (P1) in station 126). The responsible user may have asupervisor or other assistants that have also logged in and have beenassigned to such station. The notification engine 168, in response to analert being triggered via the guidance engine 152, can send thenotification to each associated user via the messaging system 150. Inthis way, timely alerts and notifications can be made to appropriatepersonnel for more timely recognition of conditions such that one ormore intervention can be made more quickly. As described herein, inaddition to such notification, the guidance engine 152 can also generatepertinent information to guide the user in such information, such asdescribed herein.

If the guidance engine determines the occurrence of an alert conditionfor a given patient 132, the corresponding alert condition can bepresented to one or more users via the user device 146. A correspondingnotification can also be sent to an individual user, as appropriatebased on notification parameters. Once an alert condition has beenpresented to a user, the user can employ the user interface 148 of theuser device 146 to acknowledge the condition. A user can intervene toremedy the condition, obtain additional information that may bepresented to the user via the user interface 148 (e.g., guidance in theform of documents, information or policies and procedures) and takeappropriate action to address the condition accordingly. Alternatively,some types of alert conditions can resolve themselves withoutintervention. Once the user believes that the condition has resolveditself or has taken steps to remedy the situation, a user can clear andremove the alert condition.

While the foregoing example has been described in the terms of an alertcondition for an individual patient 132, the system 110 can also includea dashboard module 170 that can present information associated with aplurality of stations to one or more users, such as a supervisor of afloor or ward of operating rooms. For example, the dashboard module 170can present information in a format (e.g., graphical informationsuperimposed on a floor plan) that can be easily understood by asupervisor. The representation of the floor can correspond to theindividual floor plan of the facility and the operating rooms therein.Tools can also be provided in the DSS server 112 to configure the floorplan to correspond to the actual floor plan in which the operating roomsor other types of stations 126 reside or can be based on certainconditions being met, such as patients being pediatric patients of lessthan a certain age.

Each station 126 in the representation, for example, can be color codedto provide a status indicator associated with each such station. Forinstance, a green color can be utilized to indicate that everything iswithin expected operating parameters, yellow can indicate a warningcondition, such as a previous alert condition that has resolved, and redcan be utilized to indicate an active alert condition. Additionally,icons or other information can be presented in a graphical userinterface element for each station 126. For instance, the icons can beutilized to present a user with an indication of the patient conditionsuch as real-time vital signs or other relevant patient information. Theindividual station user interface elements can also be populated withinformation including the severity and duration of physiologicalaberration (e.g., hypotension) in response to the guidance engine 152determining a corresponding alert condition exists.

Furthermore, locations may be highlighted by different methods ofemphasis such as boldness or color of the outline and frame in case ofany conditions that may require special attention, such as newconditions (i.e., conditions that did not exist in the immediatelypreceding time period) and conditions that persist beyond a certain timelimit deemed to correspond to a certain level of risk, or conditionsthat may indicate progressive risk such as that attributable to anincreasing number of hypotensive exposure limits that were exceeded

Any number of one or more criteria can be established for providingdecision support guidance that can be presented via the dashboard foreach of the plurality of stations. If an alert condition exists, acorresponding icon associated with such condition can be represented inthe station graphical user interface element to indicate a particularcondition. By hovering a cursor over a given icon, additionalinformation about the alert condition can be provided to the user. Theuser can take appropriate action based on the information presented viathe dashboard, such as may include contacting an individual who isassigned to such station (the supervising physician). Additionally, thealert can provide impetus for monitoring a given station to ensure thatappropriate action is taken to resolve the condition in a timely manner.For example, after a condition has been resolved for a given station126, the guidance engine 152 can change the condition from an alertcondition to a warning condition such that the station user interfaceelement can change from red (the alert condition) to a yellow color (awarning color) to indicate that the condition has resolved. When acondition has been resolved, but has not been cleared (corresponding toa warning condition—yellow), an individual can hover a cursor over theuser interface element or icon exhibiting the warning condition and bepresented information about the previous alert condition or conditions.For example, if a patient has hypertension and the hypertension resolvesitself, by hovering over the icon for the corresponding station, a givenuser can be informed of the extent of the hypertension, the time periodthat the hypertension occurred and when it was resolved. Additionalinformation about its resolution as well as other vitals can also beprovided, if so configured. The user can be given an option to clear thewarning condition or take other action, understanding that a person maybe prone to a given condition.

Furthermore, the color coding can be configured in such a way thatresolving physiologic aberrations can be reflected in a gradual colorchange back to normal over a period of time that is eitherpre-configurable or related to the rate of improvement of thephysiologic state.

In addition to information about patient health, the guidance engine 152can also provide information relating to equipment and the devices 130in each station such as in response to detecting a potential malfunctionof such devices or the user of such devices. As an example, the guidanceengine 152 can be programmed (e.g., via a corresponding expression) todetect a situation when a patient's blood pressure has not been takenwithin a predetermined time period (such as within the preceding 5minutes). If the blood pressure reading has not been taken within suchpredetermined period, based on the expression, an alert can be triggeredand a notification engine 168 can distribute such notification basedupon the notification parameters. Concurrently with such notificationand determination that blood pressure has not been taken the searchmodule 172 can selectively query one or more databases such as formingpart of the system data 120, to obtain information relevant to thefailure of the blood pressure to be taken, to provide additionalassistance to the user relevant to the current alert condition, such aspotential causes including that of the blood pressure monitoring devicebeing switched off. The search module 172 further can be customized fora given user, via the user interface 162 such as to implement customsearch strings for obtaining relevant data for a given station 126.Corresponding queries thus can be created in response to the guidanceengine 152 detecting the occurrence of a given condition to which thesearch string has been associated.

What have been described above are examples of the present invention. Itis, of course, not possible to describe every conceivable combination ofcomponents or methodologies for purposes of describing the presentinvention, but one of ordinary skill in the art will recognize that manyfurther combinations and permutations of the present invention arepossible. Accordingly, the present invention is intended to embrace allsuch alterations, modifications and variations that fall within thespirit and scope of the appended claims.

1. A method for monitoring a patient under anesthesia during a procedurecomprising: monitoring a physiological parameter of a patient during aprocedure at an associated sensor; measuring respective cumulative timesfor which the monitored physiological parameter of the patient meetseach of a plurality of threshold values during the procedure;calculating a risk metric for the patient, representing an effect ofmonitored physiological parameter on a patient outcome related to theprocedure from the measured cumulative times for which the monitoredphysiological parameter of the patient met each of the plurality ofthreshold values; and adjusting a level of anesthesia provided to thepatient according to the calculated risk metric, such that furtherincrease in the risk metric is minimized.
 2. The method of claim 1,wherein calculating a risk metric for the patient, comprises calculatingthe risk metric as a linear combination of respective mathematicalfunctions of the measured cumulative times.
 3. The method of claim 2,wherein the mathematical function for each cumulative time is a stepfunction, such that the linear combination of the respectivemathematical functions of the cumulative times comprises a number ofcumulative times that exceed a value associated with their associatedstep function.
 4. The method of claim 3, further comprising calculatinga risk index, representing a change in a probability of the patientoutcome related to the procedure, as an exponential function of the riskmetric.
 5. The method of claim 3, further comprising alerting anoperator each time a cumulative time exceeds the value associated withits associated step function.
 6. The method of claim 3, wherein thevalues associated with the step functions for the plurality ofcumulative times are determined according to at least one biometricparameter of the patient.
 7. The method of claim 1, wherein themonitored physiological parameter is a mean arterial blood pressure, andthe plurality of threshold values comprise a plurality of mean arterialblood pressure values between forty-five mmHg and seventy-five mmHg. 8.The method of claim 6, wherein the plurality of threshold valuescomprise each integer value between forty-five mmHg and seventy-fivemmHg.
 9. The method of claim 1, wherein the calculated risk metric iscategorical, and calculating a risk metric for the patient furthercomprises—classifying a patient into one of a plurality of risk classesto provide the risk metric.
 10. The method of claim 1, furthercomprising alerting an operator each time the calculated risk metricchanges. 11-16. (canceled)
 17. A system, implemented on at least onededicated hardware device, for predicting patient outcomes relating to aprocedure comprising: a sensor configured to detect a physiologicalparameter of a patient during the procedure; a user interface; aprocessing assembly configured to compare the detected physiologicalparameter to a plurality of defined ranges, record respective cumulativetimes for which the measured physiological parameter deviate from eachof the defined ranges, and notify an operator, via an alert at the userinterface, each time the cumulative time that the measured physiologicalparameter exceeds a maximum time associated with a given defined range.18. The system of claim 17, wherein the sensor is configured to measurea blood pressure of the patient.
 19. (canceled)
 20. A method fordetecting hypotensive exposure during anesthesia comprising: monitoringa blood pressure of a patient during a procedure at a blood pressuresensor; measuring respective cumulative times for which the bloodpressure of the patient was below each of a plurality of thresholdvalues during the procedure; and alerting a user, at an associated userdevice, when any one of the cumulative times exceeds a predeterminedexposure limit for its associated threshold value.
 21. The method ofclaim 20, the method further comprising assigning the patient to acourse of postsurgical follow-up care according to a number of theplurality of threshold values for which the cumulative time associatedwith the threshold value exceeds a predetermined exposure limit.
 22. Themethod of claim 21, wherein the plurality of threshold values compriseeach integer value between forty-five mmHg and seventy-five mmHg. 23.The method of claim 21, wherein the predetermined exposure limit foreach of the plurality of threshold values is selected as a time periodassociated with a defined progressive increase in a risk ofpost-procedure morbidity to the patient, such that each predeterminedexposure limit that is exceeded represents a same percentage increase inthe risk of post-procedure morbidity to the patient.
 24. The method ofclaim 9, the method further comprising assigning the patient to a courseof postsurgical follow-up care according to the risk class into whichthe patient was classified.